3-7 ボイス ーコッド正規形

一般的な業務の設計をする場合、第3正規化までで事足りる

複雑な業務の設計をする場合、さらに高次の正規化が必要なケースもある

第3を超える正規化をすることを、高次正規化という

3次と4次の狭間

第3正規化の次は、ボイス - コッド正規化がある

これは第3正規化をより厳密にしたもの

ボイスコッド正規化とは、非キーからキーへ関数従属をなくした状態にすること

非キーからキーへの関数従属の例

table:社員・チーム・リーダーテーブル

社員ID（複合主キー） チームコード（複合主キー） チームリーダー

000A 001 123W

000B 001 456Z

000B 002 003O

001F 001 123W

001F 002 003O

003O 002 999Y

社員と社員が属するチームの関係を表したテーブル

社員は複数チームに属することができる

チームリーダーは同じチームに複数人いる

社員が複数チームのチームリーダーを兼任することはできない

ボイスコッド正規化されていないテーブルの問題

1️⃣ 非キーとキーの関係が変わるときに、複数行の更新が発生する

例：チームリーダーの担当チームが変わるとき

2️⃣ 複合主キーが決まるまで、非キーとキーの関連を登録できない

例：社員がチームに参加するまで、チームリーダーとチームの関連づけができない

3️⃣ レコードが削除されたときに、非キーからキーへの関連が消える可能性がある

例：社員がチームから外れたときに、チームリーダーとチームの関連づけも削除される可能性がある

ボイスコッド正規化案 ❌

table:社員・チームテーブル

社員ID（複合主キー） チームコード（複合主キー）

000A 001

000B 001

000B 002

001F 001

001F 002

003O 002

table:チームリーダー・チームテーブル

チームリーダー（主キー） チームコード

123W 001

456Z 001

003O 002

999Y 002

原因は2つのテーブルが多対多の関連になっているから

正規化は常にテーブルが1対多の関連になる必要がある

ボイス - コッド正規化を行う

table:社員・チーム・リーダーテーブル

社員ID（複合主キー） チームコード（複合主キー） チームリーダー

000A 001 123W

000B 001 456Z

000B 002 003O

001F 001 123W

001F 002 003O

003O 002 999Y

⬇️

table:社員・チームリーダーテーブル

社員ID（複合主キー） チームリーダー（複合主キー）

000A 123W

000B 456Z

000B 003O

001F 123W

001F 003O

003O 999Y

table:チームリーダー・チームテーブル

チームリーダー（主キー） チームコード

123W 001

456Z 001

003O 002

999Y 002

これでテーブルの関係が1対多になったので、無損失分解ができている

しかし